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Abstract 

In this paper we focus on the development of a toolbox for the verification of programs in the context of 
SCOOP - an elegant concurrency model, recently formalized based on Rewriting Logic (RL) and Maude. 
SCOOP is implemented in Eiffel and its applicability is demonstrated also from a practical perspective, in 
the area of robotics programming. Our contribution consists in devising and integrating an alias analyzer 
and a Coffman deadlock detector under the roof of the same RL-based semantic framework of SCOOP. This 
enables using the Maude rewriting engine and its LTL model-checker “for free”, in order to perform the 
analyses of interest. We discuss the limitations of our approach for mo del-checking deadlocks and provide 
solutions to the state explosion problem. The latter is mainly caused by the size of the SCOOP formalization 
which incorporates all the aspects of a real concurrency model. On the aliasing side, we propose an extension 
of a previously introduced alias calculus based on program expressions, to the setting of unbounded program 
executions such as infinite loops and recursive calls. Moreover, we devise a corresponding executable speci¬ 
fication easily implementable on top of the SCOOP formalization. An important property of our extension 
is that, in non-concurrent settings, the corresponding alias expressions can be over-approximated in terms 
of a notion of regular expressions. This further enables us to derive an algorithm that always stops and 
provides a sound over-approximation of the “may aliasing” information, where soundness stands for the lack 
of false negatives. 

Keywords: concurrency, SCOOP, operational semantics, alias analysis, deadlock detection, Maude, 
rewriting logic 


1. Introduction 

In light of the widespread deployment and complexity of concurrent systems, the development of cor¬ 
responding frameworks for rigorous design and analysis has been a great challenge. Along this research 
direction, the focus can be two-fold. On the one hand, the interest might be on formalizing and reasoning 
about a concurrency model, its characteristic concepts and synchronization mechanisms, for instance. On 
the other hand, of equal importance, the efforts might be directed towards checking the behavior of concur¬ 
rent applications and their properties. These two research areas are closely related: it is often the case that, 
for example, analysis tools for concurrent applications depend on the underlying concurrency model. Hence, 
the development of a unifying framework for the design and analysis of both the model and its applications 
is of interest. 

In this paper we are targeting SCOOP [Ij, a simple object-oriented programming model for concurrency. 
Two main characteristics make SCOOP simple: f) just one keyword programmers have to learn and use in 
order to enable concurrent executions, and 2) the burden of orchestrating concurrent executions is handled 
within the model, therefore reducing the risk of correctness issues. The reference implementation is Eiffel Q, 
but implementations have also been built on top of languages such as Java. The success of SCOOP is 
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demonstrated not only from a research perspective, but also from a practical perspective, with applications 
appearing, for instance, in the area of robotics programming Q. 

The basis of a framework for the design and analysis of the SCOOP model has already been set. In 
this respect, we refer to the recent formalization of SCOOP in [J based on Rewriting Logic (RL) [1 which 
is “executable” and straightforwardly implement able in the programming language Maude [3- In [3 these 
capabilities have been successfully exploited in order to reason on the original SCOOP model and to identify 
a number of design flaws. 

Moreover, an executable semantics can be exploited in order to formalize and “run” analysis tools for 
SCOOP programs as well. This facilitates the extension of the aforementioned SCOOP formalization to 
the level of a unifying executable semantic framework for the design and analysis of both the model and its 
concurrent applications. In this paper we focus on the development of a RL-based toolbox for the analysis 
of SCOOP programs on top of the formalization in [ij. We are interested in constructing an alias analyzer 
and a deadlock detector. 

Alias analysis has been an interesting research direction for the verification and optimization of programs. 
One of the challenges along this line of research has been the undecidability of determining whether two 
expressions in a program may reference the same object. A rich suite of approaches aiming at providing a 
satisfactory balance between scalability andnrecision has already been developed in this regard. Examples 
include: (i) intra^rocedural frameworks [6|,l7| that handle isolated functions only, and their inter-procedural 
counterparts (3; B 0 that consider the interactions between function calls; (ii) type-based techniques (lo| : 
(iii) flow-based techniques (III . [l3 | that establish aliases depending on the control-flow information of a 
procedure; (iv) context-(in)sensitive approaches [Il,[il that depend on whether the calling context of a 
function is taken into account or not; (v) field-(in)sensitive approaches [ll,[3 that depend on whether the 
individual fields of objects in a program are traced or not. 

There is a huge literature on heap analysis for aliasing (l7| , but hardly any paper that presents a calculus 
allowing the derivation of alias relations as the result of applying various instructions of a programming 
language. Hence, of particular interest for the work in this paper is the untyped, flow-sensitive, field 
sensitive, inter-procedural and context-sensitive calculus for may aliasing, introduced in (l8| . The calculus 
covers most of the aspects of a modern object-oriented language, namely: object creation and deletion, 
conditionals, assignments, loops and (possibly recursive) function calls. The approach in [l^ abstracts the 
aliasing information in terms of explicit access paths [19j referred to as alias expressions straightforwardly 
computed in an equational fashion, based on the language constructs. As we shall see later on in this paper, 
the language-based expressions can be exploited in order to reason on “may aliasing” in a finite number of 
steps in non-concurrent settings and, moreover, can be easily incorporated in the semantic rules defining 

SCOOP in [ 3 . 

Deadlock is one of the most serious problems in concurrent systems. It occurs when two or more executing 
threads are each waiting for the other to finish. Along time, the complexity of the problem determined 
various approaches to combat deadlocks [i^. Examples include: (i) deadlock prevention which ensures 
that at least one of the deadlock conditions cannot hold, (ii) deadlock avoidance [IJ that provides a priori 
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information so that the system can predict and avoid deadlock situations, (iii) deadlock detection 
that detects and recovers from a deadlock state. 

Our focus is on deadlock detection for SCOOP programs. We base our work on the fact that this 
type of analysis is in strict connection with the underlying model of interest. Consequently, as described 
in the corresponding subsequent sections, our approach consists in formalizing deadlocks in the context 
of the SCOOP concurrency model and enriching its semantics in [3 with the equivalent operational-based 
definition of deadlocks. This enables using the Maude rewriting capabilities “for free” in order to test SCOOP 
programs for deadlock. Nevertheless, the more ambitious goal of using the Maude LTL model-checker for 
deadlock detection is not straightforward. As discussed in more detail later on in this paper, verification 
of deadlocks was possible after reducing the SCOOP semantics in (3 and abstracting it based on aliasing 
information, and modifying a series of implementation aspects (such as indexed-based parameterizations) 
that determined state explosion issues. 


2 





Our contribution. This paper is an extended version of where we proposed: 

1 . a translation of the (finite) alias calculus in [I^ to the setting of unbounded program executions such 
as infinite loops and recursive calls, together with a sound over-approximation technique based on 
(finitely representable) “regular alias expressions” capturing unbounded executions in non-concurrent 
settings; 

2. a RL-based specification of the extended calculus suitable for integration within the SCOOP formal¬ 
ization in [ij (for this purpose we chose the IK semantic framework as a RL-based formalism enabling 
compact and modular definitions); 

3. an algorithm for “may aliasing” (exploiting the finiteness property in 1.) that always terminates in 
non-concurrent settings. 

The current work adds to 1.-3. above: 

4. the full RL-based specification in 2. and the complete formal proofs showing the soundness of the 
over-approximating technique based on “regular alias expressions”; 

5. examples of exploiting the algorithm in 3. and its implementation on top of the SCOOP formalization 
in Maude [ij; 

6 . the formalization and integration of a deadlock detection mechanism on top of the SCOOP operational 
semantics [ij, together with discussions on the limitations of our approach and associated workarounds. 

Paper structure. The paper is organized as follows. In Section [2] we provide a brief overview of SCOOP. 
In Section 13] we introduce the extension of the alias calculus in [l8j to unbounded executions. In Section |3| 
we provide the full RL-based executable specification of the calculus. The implementation in SCOOP and 
further applications are discussed in SectionjS] Section|n|is dedicated to deadlocking in SCOOP. In SectionjTj 
we draw the conclusions, discuss some of the related works and provide pointers to future developments. 

2. Biref introduction to SCOOP 

As already stated, the purpose of the current work is the development of a toolbox for the analysis of 
SCOOP programs by exploiting the semantics proposed in [ij. SCOOP is particularly attractive due to 
its simplicity and elegance, as it allows the switch from sequential to concurrent programming in a rather 
straightforward fashion, by means of just one keyword, namely, separate. Transparent to the user, the 
key notion in SCOOP is the processor, or handler (that can be a CPU, or it can also be implemented in 
software, as a process or thread). Handlers are in charge of executing the routines of “separate” objects, in 
a concurrent fashion. 

For an example, assume a processor p that performs a call o./(ai, 02 ,...) on an object o. If o is declared 
as “separate”, then p sends a request for executing /(ui, 02 ,...) to g - the handler of o (note that p and q can 
coincide). Meanwhile, p can continue. Moreover, assume that 01 , 02 ,... are of “separate” types. According 
to the SCOOP semantics, the application of the call /(...) will wait until it has been able to lock all 
the separate objects associated to oi, 02 ,.... This mechanism guarantees exclusive access to these objects. 
Given a processor p, by W{p) we denote the set of processors p waits to release the resources p needs for its 
asynchronous execution. Orthogonally, by H(p) we represent the set of resources (more precisely, resource 
handlers that) p already acquired. 

The semantics of SCOOP in [l| is defined over tuples of shape 

(pi ::Sti\... \pn::Stn,a) (I) 

where, pi denotes a processor (for i G {!,..., n}), Sti is the call stack of pi and a is the state of the system. 
States hold information about the heap (which is a mapping of references to objects) and the store (which 
includes formal arguments, local variables, etc.). Processors communicate via channels. 

Roughly speaking, one could classify the operational rules formalizing SCOOP in [l[ in: a) language rules 
that provide the semantics of language constructs such as “if ... then ... else ... end” or “nntil ... loop 
... end”, and b) control rules implementing mechanisms such as locking or scheduling. 
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For an example in category a) above, consider the rules specifying “if’ instructions: 


a is fresh 

e then Sti else St2 end , St, a) —>• 

(p:: eval(a, e); wait(a);provided a.data then Sti else St2\St, a) 


ip ■.-.provided true then Sti else St2',St, a) —>• {p:: Sti', St, a) 


(p:: provided false then Sti else St2', St, a) (p:: St2', St, a) 


(3) 

(4) 


Intuitively, “eval(a, e)” evaluates e and puts the result on a fresh channel a and “wait(a)” enables processor 
p to use the evaluation result stored in a.data. It is straightforward to see that, according to ([3]), in case the 
condition e is evaluated to true then the “if branch” Sti is placed on top of the call stack of p. Otherwise, 
based on o, if e is evaluated to false, the “else branch” is executed. 

As we shall see in Section 0 an operational view on the alias calculus in [l^ exploiting the instructions 
of a programming language will enable a straightforward implementation on top of the “language rules” of 
SCOOP. 

For the case b) above we refer to the locking rule: 


Vgi € {di; ■ ■ ■; dm} : (J.rq_locked{qi) = false 
(p::lock{{qi,... qm})-,St, a) 

(p :: St, a.lock_rqs{p, {di, ■ • ■ dm})) 


stating that a processor p can lock a set of handlers {gi ,... ,qm} hy calling lock _rqs on the state a whenever 
none of the handlers qi has previously been acquired by other processors, he., a.rq_locked{qi) = false. 

As it will become clear in Section [51 “control rules” pave the way to an immediate implementation of a 
corresponding “deadlock rule” on top of the Maude formalization of SCOOP in [I| . 


3 . The alias calculus 

The calculus for may aliasing introduced in (l8| abstracts the aliasing information in terms of explicit 
access paths referred to as “alias expressions”. Consider, for an example,the case of a linked list. We write 
Xi {i > 0) to represent node i in the list, and use a setter to assign the next node of the list: 


create xq 
loop 

i: = i + 1 
create Xi 
Xi.set _next{xi-i) 

end 


( 6 ) 


The result of the execution of the code above can be intuitively depicted as the infinite sequence: 

next next next next 

a:o - xi i -... Xk-i i - Xk < - Xk+i. ■. 

Hence, xq becomes aliased to xi.next, X2.next.next, x3.next.next.next, so on and so on. In short, the set 
of associated alias expressions can be equivalently written as: 

{[xi, Xi+k-next^] I j > 0 A fc > 1}. (7) 

The sources of imprecision introduced by the calculus in jl8| are limited to ignoring tests in conditionals, 
and to “cutting at length L” for the case of possibly infinite alias relation corresponding to unbounded 
executions as in The cutting technique considers sequences longer than a given length L as aliased to 
all expressions. 
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In this section we define an extension of the calculus in (l8| . to unbounded program executions. Moreover, 
based on the idea behind the pumping lemma for regular languages (26| . we devise a corresponding sound 
over-approximation of “may aliasing” in terms of regular expressions, applicable in sequential contexts. This 
paves the way to developing an algorithm for the aliasing problem, as presented in Section SI in the formal 
setting of the K semantic framework [^. Note that K is used more as a notational convention, as its 
operational flavor enables a straightforward integration within the SCOOP formalization in [ij . 

Brief overview of the alias calculus. We proceed by recalling the notion of alias relation and a series of 
associated notations and basic operations, as introduced in |18l |. 

We call an expression a (possibly infinite) path of shape x.y.z. ..., where a: is a local variable, class 
attribute or Current, and y,z,... are attributes. Here, Current, also known as this or self, stands for the 
current object. For an arbitrary alias expression e, it holds that e. Current = Current.e = e. Let E represent 
the set of all expressions of a program. An alias relation is a symmetric and irreflexive binary relation over 
E X E. 

Given an alias relation r and an expression e, we define 

r/e = {e} U {x: A | [x, e] S r} 

denoting the set consisting of all elements in r which are aliased to e, plus e itself. 

Let X be an expression; we write r — x to represent r without the pairs with one element of shape x.e. 

We say that an alias relation is dot complete whenever for any t, u, v and a it holds that if [t, u] and \t.a, u] 
are alias pairs, then [u.a, u] is an alias pair and, moreover, if a is in the domain of t, then [t.a, u.a] is an alias 
pair. By the “domain of t” we refer to a method or a field in the class corresponding to the object referred 
by the expression associated to t. For instance, given a class NODE with a field next of type NODE, and 
a NODE object x, we say that next is in the domain oi t = x.next.next. For the sake of brevity, we write 
dot-complete{r) for the closure under dot-completeness of a relation r. 

The notation r[x = u] represents the relation r augmented with pairs [x,y\ and made dot complete, 
where y is an element of u. 

3.1. Extension to unbounded executions 

We further introduce an extension of the alias calculus in [f^ to infinite alias relations corresponding 
to unbounded executions such as infinite loops or recursive calls. The main difference in our approach is 
reflected by the definition of loops, which now complies to the usual fixed-point denotational semantics. 

The alias calculus is defined by a set of axioms “describing” how the execution a program affects the 
aliasing between expressions. As in (f8| . the calculus ignores tests in conditionals and loops. The program 
instructions are defined as follows: 

p :: = p;p\ then p else p end | 

create x | forget x | t: = s | (8) 

loop p end | call /(Z) | x.call /(Z). 

In short, we write r»p to represent the alias information obtained by executing p when starting with the 
initial alias relation r. 

The axiom for sequential composition is defined in the obvious way: 

r» {p;q) = (r » p) » q. (9) 

Conditionals are handled by considering the union of the alias pairs resulted from the execution of the 
instructions corresponding to each of the two branches, when starting with the same initial relation: 

r » (then p else q end) = r» p U r»q. (fO) 
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As previously mentioned, we define r » loop p end according to its informal semantics : “execute p 
repeatedly any number of times, including zero”. The corresponding rule is: 


r » (loop p end) = [J (r » p") 

neIN 


( 11 ) 


where U stands for the union of alias relations, as above. This way , our calculus is extended to infinite 
alias relations. This is the main difference with the approach in [18| that proposes a “cutting” technique 
restricting the model to a maximum length L. In [3, sequences longer than L are considered as aliased 
to all expressions. Orthogonally, for sequential settings, we provide hnite representations of infinite alias 
relations based on over-approximating regular expressions, as we shall see in Section Id .21 

Both the creation and the deletion of an object x eliminate from the current alias relation all the pairs 
having one element prefixed by x: 

r» (creates) = r — x , . 

r » (forget x) = r — x. ^ 

The (qualihed) function calls comply to their initial definitions in [l^ : 


r» (call/(0) = (r [/•:!])» | / | 

r » (cc.call /(/)) = x.l{x'.r) » call f{x'.1)). 


Here /* and | / | stand for the formal argument list and the body of /, respectively, whereas r[u:v] is 
the relation r in which every element of the list v is replaced by its counterpart in u. Intuitively, the 
negative variable x' is meant to transpose the context of the qualified call to the context of the caller. 
Note that “.” (i.e., the constructor for alias expressions) is generalized to distribute over lists and relations: 
a:.[a, 6 ,...] = [x.a, x.b ,...]. 

For an example, consider a class C in an 00-language, and an associated procedure / that assigns a 
local variable y, defined as: f{x){ y.= a; }. Then, for instance, the aliasing for a.call/(a) computes as 
follows: 

0 » a.call/(o) = 

a.(a '.0 » y: = a'.a) = 

a.(0 » y. = Current) = 
dot-complete{{[a.y, a]}). 

Recursive function calls can lead to infinite alias relations. In sequential settings, as for the case of loops, 
the mechanism exploiting sound regular over-approximations in order to derive finite representations of such 
relations is presented in the subsequent sections. 

The axiom for assignment is as well in accordance with its original counterpart in (l 8 | : 

r»{t:= s) = given ri = r[ot = t] - . 

then (n —t)[t = (ri/s — t)] — ot end 

where ot is a fresh variable (that stands for “old f’). Intuitively, the aliasing information w.r.t. the initial 
value of t is “saved” by associating t and ot in r and closing the new relation under dot-completeness, in 
ri. Then, the initial t is “forgotten” by computing ri — t and the new aliasing information is added in a 
consistent way. Namely, we add all pairs (t, s'), where s' ranges over ri/s — t representing all expressions 
already aliased with s in ri, including s itself, but without t. Recall that alias relations are not reflexive, 
thus by eliminating t we make sure we do not include pairs of shape [t, t]. Then, we consider again the 
closure under dot-completeness and forget the aliasing information w.r.t. the initial value of t, by removing 
ot. 


Remark 1. It is worth discussing the reason behind not considering transitive alias relations. Assume the 
following program: 

then x:= y else y:= z end 

Based on the eguations m and (ZZF handling conditionals and assignments, respectively, the calculus 
correctly identifies the alias set: {[x, y], [y, z]}. Including [x,z\ would be semantically equivalent to the 
execution of the two branches in the conditional at the same time, which is not what we want. 
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3.2. A sound over-approximation 

In a sequential setting, the challenge of computing the alias information in the context of (infinite) loops 
and recursive calls reduces to evaluating their corresponding “unfoldings”, captured by expressions of shape 

r»p‘^, 

with uj ranging over naturals plus infinity, r an (initial) alias relation (r 
defined by: 

p :: = p;p\ then p else p end | 
create x \ forget x \ 

t:= s. 

The value r » refers to the alias relation obtained by recursively executing the control block p, and it is 
calculated in the expected way: 

r»p^ = r 

^»pfe+i _ (r»p^)»p. 

Consider again the code in ([0]): 

create xq 
loop 

i: = i + 1 

create Xi 

Xi.set _next{xi-i) 

end 

Its execution generates an alias relation including an infinite number of pairs of shape: 

[xi,Xi+i.next], [xi,Xi+2-next.next], [xi, Xi+z-next.next.next] ... . (16) 

A similar reasoning does not hold for concurrent applications, where process interaction is not “regular”. 

In what follows we provide a way to compute finite representations of infinite alias relations in sequential 
settings. The key observation is that alias expressions corresponding to unbounded program executions grow 
in a regular fashion. See, for instance, the aliases in (USD, which are pairs of type \xi,Xi+k-next^-^]. 

Regular expressions are defined similarly to the regular languages over an alphabet. We say that an 
expression is regular if it is a local variable, class attribute or Current. Moreover, the concatenation ei . 62 
of two regular expressions ei and 62 is also regular. Given a regular alias expression e, the expression e* is 
also regular; here (—)* denotes the Kleene star [^. We call an alias relation regular if it consists of pairs 
of regular expressions. 

Lemma 2. Assume p a program built according to the rules in 0)- Then, in a seguential setting, the 
relation 0 » p is regular. 

In order to prove Lemma [21 we proceed by demonstrating a series of intermediate results. 

Remark 3. We first observe that the operations r/s, r — x, dot-completeness and r[x = u] introduced in 
Section\^ preserve the regularity of an alias relation r. 

Then, we define a notion of finite execution control blocks: 

p :: = create x ] forget x ] t:= s | 

p;p I then p else p end | (17) 

call f{l) I cc.call /(Z) 

where / stands for a non-recursive function. 

It is easy to see that the execution of control blocks as in m preserve the regularity of alias relations 
as well. 


= 0), and p a basic control block 


(15) 


7 


Lemma 4. For all regular alias relations r and p a finite-execution control block, in a sequential setting, it 
holds that r»p is also regular. 

Proof. The proof follows immediately, by induction on the structure of p and Remark [31 Base cases are: 
create x, forget x and t: = s. For function calls, the result is a consequence of their corresponding 
unfolding, based on the definitions in (fT31l . □ 

Remark 5. With respect to may aliasing, recursive calls can be handled via loops. Consider, for instance 
the recursive function 

fix) {Bi; f{y); B 2 } 

where Bi and B 2 are instruction blocks built as in m- It is intuitive to see that computing the may aliases 
resulted from the execution of f{x) reduces executing unfoldings of shape: 

loop Bi end; loop B 2 end. 

Moreover, unbounded program executions also preserve regularity. 

Lemma 6. For all regular alias relations r andp a control block that can execute unboundedly, in a sequential 
setting, it holds that r»p is also regular. 

Proof. The proof follows by induction on the number of nested loops in p and Remark jSl □ 

At this point, the result in Lemma [3] follows immediately by Lemma 0] and Lemma [31 
Inspired by the idea behind the pumping lemma for regular languages , we define a lasso property 
for alias relations, which identifies the repetitive patterns within the structure of the corresponding alias 
expressions. The intuition is that such patterns will occur for an infinite number of times due to the execution 
of loops or recursive function calls. Then, we supply sound over-approximations of “lasso” relations, based 
on regular alias expressions. 

In the context of alias relations, we say that the lasso property is satisfied by r and r' whenever the 
following two conditions hold: (1) r behaves like a lasso base of r'. Namely, all the pairs [ 61 , 62 ] G r are 
used to generate elements [e'^, € r' , by repeating tails of prefixes of 61 and 62 , respectively, and ( 2 ) r' is a 

lasso extension of r. Namely, all the pairs in r' are generated from elements of r by repeating tails of their 
prefixes. For example, if ei above is an expression of shape x.y.z.w, then e'l can be x.y.y.z.w if we consider 
the tail y of the prefix x.y, or x.y.z.y.z.w if we take the tail y.z of the prefix x.y.z. 

Formally, consider r and r' two alias relations, and Xi,yi and Zi a set of (possibly empty) expressions, 
for i € {1, 2}. Then: 


lasso(r,r') = i[xiyiZi,X 2 y 2 Z 2 ] G r iff [xiyiyiZi,X 2 y 2 y 2 Z 2 ] G /). (18) 

For the simplicity of notation we sometimes omit the dot-separators between expressions. For instance, we 
write xy z m. lieu of x.y.z. 

Assuming a lasso over r and r' , we compute a relation consisting of regular expressions over-approximating 
r and r' as: 

reg(r,r') = {[xiylzi,X2y2Z2] \ 

[xiyiZi,X2y2Z2] G r A ( 19 ) 

[xiyiyiZi,X2y2y2Z2\ G r'} 

where Xi,yi and Zi are possibly empty expressions, for i G {1,2}. As previously indicated, the over¬ 
approximation is sound w.r.t. the repeated application of a basic control block as in (11511 . in the way that 
it does not introduce any false negatives: 

Lemma 7. Consider r and r' two alias relations, and p a basic control block in a sequential setting. If 
r» p = r' and lasso(r, r') = true, then the following holds for all n > 1 ; 

r »p"' G reg(r, r'). 
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Proof. We proceed by induction on n. 

• Base case: n = 1. By hypothesis it holds that lasso(r, r') = true. Hence, according to the definition 
of lasso(—, —) in (fT51) . there exists a one-to-one correspondence of the shape 

[xiyiZi,X 2 y 2 Z 2 ] & r iff [xiyij/izi, a; 21 / 22 / 222 ] € r' 

between the elements of r and r', respectively. 

Consequently, by the definition of reg(—, —) in ([TO)) , it is easy to see that 

r' £ reg(r,r'). 

• Induction step. Fix a natural number n and suppose that 

r » G reg(r, r') (20) 

for all fc G {1,..., n}. We want to prove that (I^Dl) holds also for fc = n -|- 1 . 

We continue by “reductio ad absurdum”. Consider 

r = r » p" G reg(r, r'), 


and assume that 


r » p ^ reg(r, r') 


( 21 ) 


Clearly, the execution of p when starting with r identifies an alias pair which is not in reg(r, r'). Given 
that p is a basic control block as in (1151) . and based on the corresponding definitions in (I^- (IH1) . it 
is not difficult to observe that the regular structure of the alias information can only be broken via a 
new added pair (t, s') associated to an assignment t:= s within p. 

Let p = C[t:= s], where C is a context built according to (1151) . and t:= s is the upper-most assignment 
instruction in the syntactic tree associated to p, that introduces a pair [/, s'] which is not in reg(r, r'). 
Assume that r is the intermediate alias relation obtained by reducing r»C[t:= s] according to the 
equations ©-(HI, before the application of the assignment axiom corresponding to t:= s. 

Note that t:=s was executed at least once before, as n > 1, and observe that r G reg(r, r'). Hence, we 
identify two situations in the context of the aforementioned execution: (a) either all the newly added 
pairs corresponding to the assignment t:= s complied to the regular structure, or (b) each new pair 
[/', s'] that did not fit the regular pattern was later removed via a subsequent instruction “create u” 
or “forget u” within p, with u a prefix of t' or s'. 

If the case (a) above was satisfied, then, based on the definition of dot-completeness, a pair 


(t, s') G (ri — t)[t = fi/s — t] — ot, 


where 


r~i = f[ot = t] 


cannot break the regular pattern of the alias expressions either. For the case (b) above, all the “non- 
well-behaved” new pairs will be again removed via a subsequent “create it” or “forget it” within 
P- 

Therefore, the assumption in (1211) is false, so it holds that: 


r » p = r» p”'"''^ G reg(r, r'). 


□ 
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4. A K-machinery for collecting aliases 


In this section we provide the specification of a RL-based mechanism collecting the alias information 
in the K semantic framework We choose K more as a notational convention to enable compact and 
modular definitions. In reality, the K-rules in this section are implemented in Maude, as rewriting theories, 
on top of the formalization of SCOOP [ij (we refer to Section 0 for more details on our approach). 

In short, our strategy is to start with a program built on top of the control structures in (|5]), then 
to apply the corresponding K-rules in order to get the “may aliasing” information in a designated K-cell 
(( - )al)- Independently of the setting (sequential or concurrent) one can exploit this approach in order to 
evaluate the aliases of a given finite length L. We also show that for sequential contexts, the application of 
the K-rules is finite and the aliases in the final configuration soundly over-approximate the (infinite) “may 
alias” relations of the calculus. 


Brief overview o/ K. K is an executable semantic framework based on Rewriting Logic Q. It is 
suitable for defining (concurrent) languages and corresponding formal analysis tools, with straightforward 
implementation in K-Maude [ 2 ^. K-definitions make use of the so-called cells, which are labelled and can 
be nested, and (rewriting) rules describing the intended (operational) semantics. 

A cell is denoted by ( — )|name|) where [name] stands for the name of the cell. A construction ( . )„ 
stands for an empty cell named n. We use “pattern matching” and write ( c .. .)n for a cell with content c 
at the top, followed by an arbitrary content (...). Orthogonally, we can utilize cells of shape (... c )n and 
( ... c... )n, defined in the obvious way. 

Of particular interest is ( — )k ~ the continuation cell, or the k-cell, holding the stack of program 
instructions (associated to one processor), in the context of a programming language formalization. We 
write 

{ ii r\i2 .. .)k 


for a set of instructions to be “executed”, starting with instruction ii, followed by 12 - The associative 
operation r\ is the instruction sequencing. 

A K-rewrite rule 

( C . . .)ni ( C )rt 2 { C . . .)ni {■ ■ ■ C )n3 (22) 


reads as: if cell ni has c at the top and cell n 2 contains value c', then c is replaced by d in ni and d is 
added at the end of the cell nz- The content of remains unchanged. In short, (l22ll is written in a K-like 
syntax as: 


{ C . . .)ni 

d 


( C ' )„2 



We further provide the details behind the K-specification of the alias calculus. As expected, the A:-cell 
retains the instruction stack of the object-oriented program. We utilize cells (— )ai to enclose the current alias 
information, and the so-called back-tracking cells (—)bkt-... enabling the sound computation of aliases for 
the case of then — else — end and, in non-concurrent contexts, for loops and (possibly recursive) function 
calls. As a convention, we mark with (J|k) the rules that are sound only for non-concurrent applications, 
based on Lemma [T] 

The following K-rules are straightforward, based on the axioms in Section [XT] Namely, the rule 

implementing an instruction p ; q simply forces the sequential execution of p and q by positioning p r\ q at 
the top of the continuation cell: 


( p;g ••Tk 
p r\ q 


(23) 


Handling create x and forget x complies to the associated definitions. Namely, it updates the current 
alias relation by removing all the pairs having (at least) one element with x as prefix. In addition, it also 
pops the corresponding instruction from the continuation stack: 


( r )ai ( create a: .. .)k 


( r )al 


( forget X .. .)k 


(24) 


r — X 
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r — X 







The assignment rule restores the current alias relation according to its axiom in (I14II . and removes the 
assignment instruction from the top of the fc-cell: 


(_ r _ )ai ( t:= s .. .)k 

(ri -t)[t = (n/s - t)] - ot 


with ri = r[ot = t] 


(25) 


The K-implementation of a then p else q end statement is more sophisticated, as it instruments a 
stack-based mechanism enabling the computation of the union of alias relations r»p U r » g in three steps. 
First, we define the K-rule: 


( r ) 


'al 


( then p else q end 
p et q I ee | 


. .)k ( 


( r,p )t ( r,g )e 


■ • ■)bkt- 


-te 


(26) 


saving at the top of the back-tracking stack (— )bkt-te the initial alias relation r to be modified by both p and 
q, via two cells {r,p)t and (r, g)e, respectively. Note that the original instruction in the fc-cell is replaced by 
a meta-construction marking the end of the executions corresponding to the then and else branches with 
et and | ee | , respectively. 

Second, whenever the successful execution of p (signaled by et ) at the top of the fc-cell) builds an alias 
relation r', the execution of q starting with the original relation r is forced by replacing r' with r in (— )ai, 
and by positioning q \ ee | at the top of the /c-cell. The new alias information after p, denoted by (r',p)t, is 
updated in the back-tracking cell: 


r' )al 

( et 

qfiil . 

• •)k ( ( r,p )t ( r,g )e . 

•)bkt-te 

r 

9 

ee 1 

( r',p )t 



(27) 


Eventually, if the successful execution of q (marked by | ee | at the top of (— )k) produces an alias relation 
r", then the final alias information becomes r' U r" , where r' is the aliasing after p, stored as showed in (EZD- 
The corresponding back-tracking information is removed from (—)bkt-te) and the next program instruction 
is enabled in the /c-cell: 


{ r” )ai ( ■ •)k ( { r',p )t {r,q )e .. .)bkt-te ,28) 

For loop p end, we utilize a meta-construction p loop p end simulating the set union in (ITT|l . and 
a back-tracking stack {—)bkt-i collecting the alias information obtained after each execution of p. Moreover, 
the K-implementation exploits the result in Lemma [71 Whenever a “lasso” is reached, the infinite rewriting 
is prevented by resuming the infinite application of p in terms of a sound over-approximating alias relation. 
The K-rules are as follows. 

First, the aforementioned unfolding is performed, and the alias relation before p is stored in the back¬ 
tracking cell as (r)ai-o(p)i: 


( loop pend ...}k ( . .. .)bkt-i 

p 1 1 1 loop p end ( r )ai-o( P )i 

If the alias relation r' obtained after the successful execution of p (marked by at the top of the 
continuation) is not a lasso of the aliasing r before p (previously stored in (—)bkt-i) then p is constrained to 
a new execution by becoming the top of the fc-cell, and r' is memorized for back-tracking: 


( r' )al 


( [T| loop p end .. .)k 
p I 11 loop p end 


{ ( ^ )al-o{ P )l ■ • ■)bkt-l 
( r' )al-o( P )l 


if not lasso(r, r') (Jit) 


(30) 


Last, if a lasso is reached after the execution of p, then the current aliasing is soundly replaced by a 
“regular” over-approximation reg(r, r'), the corresponding back-tracking information is removed from (—)bkt-i 
and the loop instruction is eliminated from the fc-cell: 


( r_)a, ( Q] loop p end .. .)k ( ( r )ai-o{ p )i . ■ .)bkt-i inasso(r,r') (*' 

reg(r, r ) . . \ ^ / v . 


(31) 
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For handling function calls such as call/(Z) we use a meta-construction | / | [7] . Here | / | stands 

for the body of / and marks the end of the corresponding execution. Moreover, a stack (— )bkt-cf is 
utilized in order to store the alias information before each (possibly recursive) call of /, with the purpose 
of identifying the lassos generated by the (possibly repeated) execution of /. In order to guarantee a sound 
implementation of (mutually) recursive calls, both and (— )bkt-cf are parameterized by / - the name of 
the function. An example illustrating this reasoning mechanism is provided in Section 14.11 

The first K rule for handling function calls matches the associated axiom in (fTTH) : the alias information is 
set to r[f*:l], whereas the next instructions to be executed are given by | / |. Note that the original aliasing 
is retained in the (initially empty) back-tracking cell via (r)ai-o- 


r }al ( call/(I) . . .)k ( . )bkt-cf 

^ )ai- 


Remark 8. Observe that the back-tracking cell does not need to be parameterized by the actual argument 
list I of f. Each such argument is anyways replaced in the current alias relation r by its counterpart in the 
formal argument list of f. In short: r becomes r[/*:/]. 


A successful execution of call f{l) is distinguished by the occurrence of at the top of the continuation 
stack. If this is the case, then the corresponding back-tracking alias information is removed from (— )bkt-cf 
and the next program instruction (if any) is enabled at the top of the Ic-cell: 


( r' )al ^ HL • • •)k < < ^ 7l-o ■ • ■>bkt-cf ^ 33 ^ 

Recursive calls are treated by means of two K-rules. Note that a recursive context is identified whenever 
the current program instruction is of shape call f[l) and the associated back-tracking structure is not empty, 
ie., rule (1321) was previously applied. Then, if the recursive call of / when starting with r produces a lasso 
r', the execution of f{l) is stopped by soundly over-approximating the alias information with reg(r, r'), 
according to Lemma [71 and by removing callf(l) from the fc-cell: 


{ r )ai ( call y(/)...)k j j \ \ .pn / /\ (%\ 

^ ^ ^ 7l-o ■ • ■)bkt-cf if lasso(r, r ) (*) 


(34) 


If a lasso is not reached, then the body of / is executed once more, and the current aliasing is pushed to 
the back-tracking cell: 


{r'> 


al 


( call/(0 ...)k 


( 


{ r )al-o . . .)bkt-cf 


if not lasso(r, r^) (J|k) 


(35) 


/I [ij 

Qualified calls x.call f{l) are handled by two K-rules as follows. First, based on the definition in (ITSl) . the 
“negative variable” x' transposing the context of the call to to the context of the caller is distributed to the 
elements of the initial alias relation r, and to I - the argument list of /. Moreover, a meta-construction qf 


is utilized in order to mark the end of the qualified call in the continuation cell, similarly to the rule (1321) . 
The caller is stored in a back-tracking stack ( . )bkt-qf also parameterized by / - the name of the function. 
The current instruction in the fc-cell becomes call/(a:'./), as expected: 


r )al 

x' .r 


{ x.cal\f{l) ...)k ( 


call f{x'.l) qf 


) bkt-qf 


( X 


(36) 


Second, when the successful termination of the qualified call is signaled by qf at the top of the fc-cell. 


the corresponding stored caller is distributed to the current alias relation and removed from the back-tracking 
cell. The next instruction in the continuation cell is released by eliminating the top 


qf 


( J_ >al 
x.r 


<M ...)k •) bkt-qf 


(37) 
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In a non-concurrent setting, the machinery orchestrating the K-rules introduced in this section imple¬ 
ments an algorithm that always terminates and provides a sound over-approximation of “may aliasing”. 

Theorem 9. Consider p a program built on top of the control structures in that executes in a sequential 
setting. Then, the application of the corresponding M.-rules when starting with p and an empty alias relation, 
is a finite rewriting of shape 

{ 0 )al( P )k ^ {r )al( • )k, 

with r a sound over-approximation of the aliasing information corresponding to the execution ofp. 

Proof. The key observation is that, due to the execution of loops and/or recursive calls, expressions can 
infinitely grow in a regular fashion. Hence, a lasso is always reached. Consequently, the control structure 
generating the infinite behaviour is removed from the fc-cell, according to the associated K-specification for 
loops and/or recursive calls. This guarantees termination. Moreover, recall that the regular expressions 
replacing the current alias information are a sound over-approximation, according to Lemma 0 □ 

Observe that the i?L-based machinery can simulate precisely the “cutting at length L” technique in (l8| . 
It suffices to disable the rules (♦) and stop the rewriting after L steps. 

The naturalness of applying the resulted aliasing framework is illustrated in the example in Section 14.11 
for the case of two mutually recursive functions. 

/.I. The H-machinery by example 

For an example, in this section we show how the K-machinery developed in Section 0] can be used in 
order to extract the alias information for the case of two mutually recursive functions defined as: 

f{x) {x\= x.a; call 5 ( 0 ;) } g{x) { x:= x.b; caUf(x) } 

We assume that x is an object of a class with two fields a and b, respectively. We consider a sequential 
setting. 

At first glance it is easy to see that the execution of call f{x), when starting with an empty alias relation 
r, produces the alias expressions: 

[x, x.{a.b)*] [x.a, x.{a.b)*.a\ [x.b, x.{a.b)*.b] (38) 

The associated reasoning in K is depicted in Figure 14.11 The whole procedure starts with an empty 
alias relation r = 0, and call /(a;) in the continuation stack. Then, the corresponding K rules (for handling 
assignments and function calls) are applied in the natural way. 

A lasso is reached after two calls of f{x) that, consequently, determine two calls of g{x) - identified 
by @ 0 @ 0 in the A:-cell. This triggers the application of rule (IMll enabling the “regular” over¬ 
approximation as in Lemma [71 

Our example also illustrates the importance of isolating the back-traced alias information in cells of 
shape ( . )bkt-cf parameterized by the (possibly recursive) function /. More explicitly, rule ((Ml) is soundly 
applied by identifying the aforementioned lasso based on: the current alias relation r^, the recursive call f{l) 
at the top of the continuation, and the back-traced aliasing ( ( r 2 )ai-o ■ • /bkt-cf associated to the previous 
executions of f{l). 

As introduced in m, an alias relation r' is a lasso of a relation r whenever there is a one-to-one 
correspondence between their elements as follows: 

[xiyiZi,X 2 y 2 Z 2 ] G r iff [xiyiyiZi,X 2 y 2 y 2 Z 2 \ G r'. 

The current alias relation 

r 4 = {[x,x.a.b.a.b], [x.a,x.a.b.a.b.a], [x.b,x.a.b.a.b.b]}. 
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before applying rule (|M)) . is a lasso of 


1^2 = {[x,x.a.b], [x.a,x.a.b.a], [x.b,x.a.b.b]}. 


The aforementioned one-to-one correspondence is summarized in the following table: 


[xiyizi,X2y2Z2\ S r2 iff [xiyiyizi,X2y2y2Z2] G r4 

xi 

yi 


X2 

y2 

Z2 

[x,x.a.b] € r2 iff [x^x.a.b.a.b] € ^4 

X 

€ 

£ 

X 

a.b 

£ 

[x.a,x.a.b.a] £ r2 iff [x.a,x.a.b.a.b.a] £ 

X 

£ 

a 

X 

a.b 

a 

[x.b,x.a.b.h\ £ r2 iff [x.b,x.a.b.a.b.b] £ r4 

X 

£ 

b 

X 

a.b 

b 


Here e stands for the empty alias expression. 

Moreover, according to rule (1341) . the lasso shaped by r 2 and r 4 also causes the (otherwise infinite) 
recursive calls to stop, as call/(Z) is eliminated from the top of the fc-cell. Hence, the rewriting process 
finishes with a sound over-approximation reg(r 2 ,r 4 ) replacing the current alias relation (cf. Lemma [7]), 
defined precisely as in (1551) . 


5. Aliasing in SCOOP 


In this section we provide a brief overview on the integration and applicability of the alias calculus in 
SCOOP. First, recall from Section that the Maude semantics of SCOOP in [ij is defined over tuples of 
shape 

{pi::Sti I ... \pn::St„,a) 

where, pi and SU stand for processors and their call stacks, respectively, a is the state of the system and it 
holds information about the heap and the store. 

The assignment instruction, for instance, is formally specified as the transition rule: 


a is fresh 

PF {p::t: = s]St, a) —?• (p:: eval(a, s); wait(a); write(t, a.dato); S't, a) 


(39) 


where, intuitively, “eval(a, s)” evaluates s and puts the result on channel a, “wait(a)” enables processor p to 
use the evaluation result, “write(t, a.datay^ sets the value of t to a.data, St is a call stack, and T is a typing 
environment (3fll | containing the class hierarchy of a program and all the type definitions. 

At this point it is easy to understand that the K-rule for assignments 


(. 


(ri - t)[t = (ri/s - t)\ - ot 


)ai ( t:= s ...) 


k with ri = r[ot = t] 


can be straightforwardly integrated in (|39p by enriching the SCOOP configuration with a new component 
alias _ encapsulating the alias information, and considering instead the transition: 


r h (p :: < : =s; S't, tr, aliaSoid) — t 
(p:: eval(a, s); wait(a); write(t, a.data); St, a, aliasnew) 


where 

alias old = r aliaSnew = (n -t)[t = (ri/s - t)] - ot 

with r and ri as in (1551) . The integration of all the K-rules of the alias calculus on top of the Maude 
formalization of SCOOP is achieved by following a similar approach. 

For a case study, one can download the SCOOP formalization at: 
https://dl.dropboxusercontent.com/u/1356725/SCOOP-SCP.zip 
and run the command 
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( r )ai ( call/(a;) )k 

( ■ )bkt-cf \ ■ )bkt-cg 

(EH 

( r )ai {x:= x.a;caUg{x) |T| )k 

( ( ^ ) al-o ) bkt-cf ( ■ ) bkt-cg 

( ri )ai ( call5(x) 0 )k 
( ( r )al-o ) bkt-cf ( ■ ) bkt-cg 

where ri = {[x,x.a], [x.a,x.a.a], [x.b^x.a.b]} 

JJ- (155)1 

{ )ai {x:= x.6;call/(x) [g] 0 )k 

( ( ^ )al-o ) bkt-cf { { )al-o ) bkt-cg 

{ r 2 )ai ( call/(x) 0 )k 
( ( f )al-o )bkt-cf { { ff ) al-o ) bkt-cg 

where r 2 = {[x,x.a.b], [x.a^x.a.b.a], [x.b^x.a.b.b]} 

dSSD 

( f 2 )ai {x:= x.a;caUg{x) 0 [0 0 )k 

( ( ^2 )al-o ( f )al-o ) bkt-cf ( ( f’l )al-o ) bkt-cg 

(USD 

( f3 )al ( call5(x )[I10 0 >1. 

( ( f2 )al-o ( f )al-o ) bkt-cf ( ( f*l )al-o ) bkt-cg 

where = {[x,x.a.b.a], [x.a,x.a.b.a.a], [x.b,x.a.b.a.b]} 

JJ- (155)1 

( f 3 )ai {x:= x.b;caUf{x) |0 0 0] 0 )k 

( ( ^*2 ) al-o ( f ) al-o ) bkt-cf ( ( ^3 ) al-o ( ) al-o ) bkt-cg 

JJ 015)1 

( Ti )al ( call/(x) [0 0 [0 0 )k 
( ( ^2 )al-o ( ^ )al-o ) bkt-cf { { ^3 )al-o ( '^ 1 )al-o , ) bkt-cg 

where r 4 = {[x,x.a.b.a.b], [x.a,x.a.b.a.b.a], [x.b,x.a.b.a.b.b]} 

JJ OMl) 

( reg{r2,ri) )ai ( 10 0 0 0 

( ( f2 )al-o ( f )al-o ) bkt-cf ( \ f3 ) al-o ( W )al-o ) bkt-cg 

JJ (*)0551) 

( {[x,x.{a.b)*], [x.a,x.{a.b)*.a\, [x.b,x.{a.b)*.h]} )ai( . )k( ■ )bkt-ct( • )bkt-cg 


Figure 1: Aliasing and mutual recursion in K. 
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> maude SCOOP.maude ..\exainples\linked_list-test.maude 
corresponding to the execution of the code in (jS]) 

create xq 
loop 

i: = i + 1 
create xi 
Xi .set _next{xi-i) 

end 

for five iterations of the loop. As can be observed based on the code in aliasing-linked_list .maude, 
in order to implement our applications in Maude, we use intermediate (still intuitive) representations. For 
instance, the class structure defining a node in a simple linked list, with filed next and setter set_next is 
declared as: 

class ’NODE 

create {’make} ( 

attribute { ’ANY } ’next ’NODE] ; 

procedure { ’ANY } ’set_next ( ’a_next : [?, ., ’NODE] ;) [...] 

) 

end ; 

where ’next : [?, . , ’NODE] stands for an object of type NODE, that is handled by the current processor 
(.) and that can be Void (?), and ’make plays the role of a constructor. The “entry point” of the program 
corresponds to the function ’make in the (main) class ’LINKED_LIST_TEST and is set via: 

settings(’LINKED_LIST_TEST, ’make, aliasing-on) . 

Observe that the flag for performing the alias analysis is switched to “on”. 

The relevant parts of the corresponding Maude output after executing the aforementioned command are 
as follows: 


\l I I I I I I I I I I I I I I I I 1/ 

- Welcome to Maude - 

/I I I I I I I I I I I I I I I I I l\ 

Maude 2.6 built: Mar 31 2011 23:36:02 

rewrite in SYSTEM : 

[...] settings(’LlNKED_LlST_TEST, ’make, aliasing-on)) 


{0}proc(0) :: nil I {0}proc(l) :: nil, 

{[’xO ; ’xO]} U {[’xO ; ’xl.’next]} U 

{[’xO ; ’x2.’next.’next]} U {[’xO ; ’x3.’next.’next.’next]} U 
{[’xO ; ’x4.’next.’next.’next.’next]} U 

[. . .] 

{[’x3 ; ’x3]} U {[’x3 ; ’x4.’next]} 


state 

heap [.. . ] 
store [... ] 
end 


In short, one can see that two processors that were created finished executing the instructions on their 
corresponding call stacks: {0}proc(0) :: nil and {0}proc (1) :: nil. The aliased expressions include, 
as expected based on pairs of shape [xi ; Xi+fe.next^]. Moreover, the output displays the contents of the 
current system state, by providing information on the heap and store., as formalized in [ij. 
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6. Deadlocking in SCOOP 


In what follows we provide the details behind the formalization and the implementation of a deadlock 
detection mechanism for SCOOP. We discuss how Maude can be exploited in order to test and, respectively, 
model-check deadlocks in the context of SCOOP programs, we analyze the associated challenges and propose 
a series of corresponding solutions. 

6.1. Formalizing deadlocks in SCOOP 

Recall that the key idea of SCOOP is to associate to each object declared as separate a processor, or 
handler in charge of executing the routines of that object. Assume a processor p that performs a call 
o./(ai, 02 ,...) on a separate object o, with separate arguments o^ (i > 1). As previously stated in Section[51 
in the SCOOP semantics, the application of the call /(...) will wait until it has been able to lock all the 
separate objects associated to 01 , 02 ,.... This reservation mechanism enables deadlocks to occur whenever 
a set of processors reserve each other circularly. This situation might happen, for instance, in a Dining 
Philosophers scenario, where both philosophers and forks are objects residing on their own processors. 

Definition 10 (Deadlock). For a processor p, let W (p) be the set of handlers p waits for its asynchronous 
execution, and Fliji) represent the set of resources p already acquired. A deadlock exists if for some set D 
of processors the following holds: 

(Vp G D).(3p' G D).{p ^ p) A (IT(p) n H{p) = 0). (40) 

The integration of a deadlock detection mechanism based on Definition [TU] on top of the SCOOP for¬ 
malization in [H is immediate. As already presented in Section [21 the operational semantics of SCOOP is 
defined over tuples of shape: 

(pi ::Sti\...\p„ :: Stn,(j) 

where, pi and Sti stand for processors and their call stacks, respectively, and a is the state of the system. 
Given a processor p' as in (HHll . the set H{p') corresponds, based on [ij, to a.rq_locks{p'). Whenever the top 
of the instruction stack of a processor p is of shape lock{{qi ,..., g„}), we say that the wait set W{p) is the 
set of processors {qi ,..., Qn}. Hence, assuming a predefined system configuration {deadlock), the SCOOP 
transition rule in Maude corresponding to (1401) can be written as: 

{3D C a.procs).{'ip G D).{3p' G D).{p ^ p')A 
{aqs: = ... \ p::lock{{qi,.. .});St \ ...) A {a.rq_locks{p').has{qi)) 

{aqs, a) —>• {deadlock) 

It is intuitive to guess that a.procs in (ITTl) returns the set of processors in the system, whereas aqs stands 
for the list of these processors and their associated instruction stacks (separated by the associative and 
commutative operator “|” ). We use “...” to represent an arbitrary sequence of processors and processor 
stacks. 

6.2. Testing deadlocks 

We implemented dUD and tested the deadlock detection mechanism on top of the formalization in [Ij for 
the Dining Philosophers problem. A case study considering two philosophers sharing two forks can be run 
by downloading the SCOOP formalization at: 

https://dl.dropboxusercontent.com/u/1356725/SCOOP-SCP-deadlock.zip 
and executing the command 

> maude SCOOP.maude ..\exainples\dining-philosophers-rewrite.maude 
The class implementing the philosopher concept is briefly given below: 
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(class ’PHILOSOPHER 
create { ’make } ( 

attribute {’ANY} ’left : [!,T,’F0RK] ; 
attribute {’ANY} ’right : [!,T,’F0RK] ; 

procedure { ’ANY } ’make ( ’fl : [!,T,’F0RK] ; 

’fr : [!,T,’F0RK] ; ) 

do ( assign (’left, ’fl) ; assign (’right, ’fr) ; ) 

[. . .] 

end ; 

procedure { ’ANY } ’eat_wrong (nil) 

do ( command (’Current . ’pick_in_turn(’left ;)) ; ) 

[. . .] 

end ; 

procedure { ’ANY } ’pick_in_turn (’f : [!,T,’F0RK] ; ) 

do ( commcuid (’Current . ’pick_two(’f ; ’right ;)) ; ) 

[. . .] 

end ; 

procedure { ’ANY } ’pick_two (’fa : [!,T,’F0RK] ; 

’fb : [!,T,’F0RK] ; ) 
do 

( 

command (’fa . ’use(nil)) ; 
command (’fb . ’use(nil)) ; 

) 

[. . .] 

end ; 

[...] end) 

It declares two forks - ’left and ’right of type ’FORK, that can be handled by any processor (T) and that 
cannot be Void (!). Assume two philosophers pi and p2 (of separate type PHILOSOPHER) and two forks fl 
and f 2 (of separate type FORK). Moreover, assume that ’left and ’right for pi correspond to ’f 1 and ’f 2. 
For the case of p2 they correspond to ’f2 and ’f 1, respectively. Asynchronously, pi and p2 can execute 
eat_wrong, which calls pick_in_turn(left). In the context of pi, the actual value of left is f 1, whereas 
for p2 is f2. Consequently, both resources f 1 and f2, respectively, may be locked “at the same time” by pi 
and p2, respectively. Note that pick_in_turn subsequently calls pick_two that, intuitively, should enable 
the philosophers to use both forks. Thus, if fl and f2, respectively, are locked by pi and p2, respectively, 
the calls pick_two(f2, fl) and pick_two(fl, f2) corresponding to pi and p2 will (circularly) wait for 
each other to hnish. According to the SCOOP semantics, pick_two(fl, f2) is waiting for p2 to release 
f2, whereas pick_two(f2, f 1) is waiting for pi to release f 1, as the forks are passed to pick_two(. . .) as 
separate types. In the context of SCOOP, this corresponds to a Coffman deadlock (^ . 

The entry point of the program implementing the Dining Philosophers example is the function ’make 
in the class APPLICATION, which asks the two philosophers pi and p2 to adopt a wrong eating strategy as 
above, possibly leading to a deadlock situation. The flag enabling the deadlock analysis as in dni) is set to 
“on”. This information is specified using the instruction settings!’APPLICATION, ’make, deadlock-on). 

Unfortunately, none of the executions of the Dining Philosophers scenario by simply invoking the Maude 
rewrite command lead to a deadlock situation. Each of our tests displayed the output: 
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rewrite in SYSTEM : 

[...] settings(’APPLICATION, ’make, deadlock-on) 


- {0}proc(0) : 

: nil 

{0}proc(l) : 

nil 1 {0}proc(3) : 

: nil 

{0}proc(5) : 

: nil 

{0}proc(7) : 

nil 


{0}proc(9) : 

: nil 

{0}proc(ll) 

: nil 



consisting of a list of processors (including the handlers of both the philosophers and the forks) with empty 
call stacks (: : nil). This indicates that every time, the two philosophers proceeded by lifting their forks 
simultaneously, hence no deadlock was possible. 

One possible workaround is to use predefined strategies in order to guide the rewriting of the Maude 
rules formalizing SCOOP towards a {deadlock) system configuration. An example of applying such a strategy 
for the Dining Philosophers case can be tested by running the command: 

> maude SCOOP.maude ..\exajnples\dining-philosophers-strategy.maude 

The command srew [...] using init ; parallelismflock} ; [...] ; deadlock-onforces the ex¬ 
ecution of a pick_in_turn amroach as above. This determines Maude to first trigger the rule [init] in 
the SCOOP formalization in [l|. This makes all the required initializations of the bootstrap processor. Then, 
one of the processors that managed to lock the necessary resources is (“randomly”) enabled to proceed to the 
asynchronous execution of its instruction stack, according to the strategy parallelismflock} . The last 
step of the strategy calls the rule [deadlock-on] implementing the Coffman deadlock detection as in (51]). 

This time the guided rewriting leads, indeed, to one solution identifying a deadlock. The relevant parts 
of the corresponding Maude output are as follows: 

\l I I I I I I I I I I I I I I I I 1/ 
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srewrite in SYSTEM : 

[...] settingsC’APPLlCATlON, ’make, deadlock-on) 
using init ; parallelism-flock} ; [...] ; deadlock-on . 

Solution 1 

rewrites: 479677 in 2674887330ms cpu (7379ms real) (0 rewrites/second) 
result Configuration: deadlock 

No more solutions. 

rewrites: 479677 in 2674887330ms cpu (7453ms real) (0 rewrites/second) 

Nevertheless, such an approach requires lots of ingeiiiousness (our strategy has more than 300 rules!) 
and, moreover, is not automated. 

6.3. Model-checking deadlocks 

In this section we provide an overview on our approach to model-checking deadlocks for SCOOP, using 
the LTL Maude model-checker [^. As mentioned in the beginning of the current paper, the idea behind 
our work is to exploit the unifying flavor of the Maude executable semantics of SCOOP [ij. The latter 


19 





integrates both the formalization of the language and its concurrency mechanisms, thus enabling using the 
semantic framework for program analysis purposes, “for free”. 

One possible way to proceed is by simply running the Maude LTL model-checker via a search com¬ 
mand. For model-checking deadlocks, one could invoke search [b, d] subject =>* deadlock. In a 
Dining Philosophers setting, for instance, this corresponds to performing a breadth-first search starting with 
subject - the corresponding (intermediate Maude representation of the) SCOOP program - to a deadlock 
state, in zero or more steps of proof (=>*)■ The optional arguments b and d provide an upper bound in the 
number of solutions to be found and, respectively, the maximum depth of the search. 

Unfortunately, running the aforementioned search command led to the state explosion problem. At a 
first look, the issue was caused by the size of the SCOOP formalization in [ij which includes all the aspects 
of a real concurrency model. 

As a first step, we reduced this formalization by eliminating the parts that are not relevant in the context 
of deadlocking; examples include the garbage collection and the exception handling mechanisms. 

In addition, we provided a simplified, abstract semantics of SCOOP based on aliasing. This idea stems 
from the fact that SCOOP processors are known from object references, that may be aliased. Therefore, 
the SCOOP semantics can be simplified by retaining within the corresponding transition rules only the 
information important for aliasing. Consider, for instance, the rules ([1])-(|1]) specifying “if’ instructions in 
Section [5J The abstract transition rule omits the evaluation of the conditional and computes the aliasing 
information similarly to the semantics of then ... else ... end in (fm . in Section[31 The abstraction collects 
the aliases resulted after the execution of both “if’ and “else” branches: 


(p::if e then Sti else St 2 end, St, a, alias old) 

{p::St, a,aliasnew) 

Observe that the SCOOP system configurations in ([T]) are enriched with a new component alias _ consisting 
of a set of alias expressions. Above, aliasoid is the aliasing before the execution of the “if’ instruction, 
whereas, intuitively, aliasnew stands for alias old » Sti U aliasoid » St 2 - 

As a second step, we analyzed the implementation in P| from a more engineering perspective, and 
identified a series of design decisions that either slowed down considerably the rewriting or made the search 
space grow unnecessarily large. 

After running some experiments, we understood that the parallelism rule 


_ {Pi ■■Sti, <J) {p[ a') _ 

(pi :: Sti I p 2 St 2 , a) -)■ {p'l :: St[ \ p 2 :: St 2 , &) 

in [ij was increasing the rewriting time. Though elegant from the formalization perspective, the usage of 
this rule was not efficient. Therefore, we eliminated it from the SCOOP semantics and made the remaining 
rules apply directly, by matching at top. For instance, the abstract rule formalizing “if’ instructions in 
the context of one processor p becomes: 


(p::if e then Sti else St 2 end , St \ aqs, a,aliaSoid) —t 
{p::St I aqs, a,aliaSnew) 

for an arbitrary list aqs of processors and their instruction stacks. For Dining Philosophers, for example, 
this modification reduced the rewriting time from around 10s to less than Is. 

Recall that SCOOP processors communicate via channels. The implementation in [ij creates fresh 
channels (as in Q, for instance) parameterized by natural indexes. This was inefficient for model-checking 
purposes, as the state space contained many identical states up-to channel naming. 

The implementation of the above observations enabled us to successfully identify a deadlock situation in 
a Dining Philosophers scenario, by using the Maude LTL model-checker. The new (reduced) formalization 
of SCOOP can be found at: 

https://dl.dropboxusercontent.com/u/1356725/SCOOP-SCP.zip 
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whereas the example considering two philosophers can be run by executing the command 
> maude SCOOP.maude ..\exainples\dining-philosophers-model-check.maude 
A bounded search successfully identifies one deadlock: 

\l I I I I I I I I I I I I I I I I 1/ 
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Copyright 1997-2010 SRI International 


search [1, 200] in SYSTEM : 

[...] settings(’APPLICATION, ’make, deadlock-on) =>* deadlock . 

Solution 1 (state 769167) 
states: 769168 

rewrites: 342475817 in 2674905322ms cpu (1226403ms real) 

The amount of time necessary for mo del-checking is still quite large (approximately 20mins for the 
example above). However, further improvements may be obtained by following the same recipe of col¬ 
lapsing semantically equivalent states, from the deadlocking perspective. A major source of redundancy 
is represented by the so-called regions in [ij that, intuitively, manage all the objects handled by the same 
processor. Their elimination from the SCOOP abstract state would enable the model-checker to make less 
identifications, therefore improving the overall time performance. 


7. Discussion 

The focus of this paper is on building a toolbox for the analysis of SCOOP programs, with emphasis on 
an alias analyzer and a deadlock detector. The naturalness of our approach consists in exploiting the recent 
formalization of SCOOP in [ij, that is executable and implemented in Maude This provides a unifying 
framework that can be used not only to reason about the SCOOP model and its design as in [l|, but also 
to analyze SCOOP programs via Maude rewriting and model-checking. 

Of particular interest for the aliasing tool is the calculus introduced in [I^ , which abstracts the aliasing 
information in terms of explicit access paths referred to as “alias expressions”. We provide an extension of 
this calculus from finite alias relations to infinite ones corresponding to loops and recursive calls. Moreover, 
we devise an associated RL-based executable specification in the K semantic framework . In Theorem IH] 
we show that the RL-based machinery implements an algorithm that always terminates with a sound over¬ 
approximation of “may aliasing”, in non-concurrent settings. This is achieved based on the sound (finitely 
representable) over-approximation of alias expressions in terms of regular expressions, as in Lemma [7l The 
integration of the alias calculus on top of the Maude formalization of SCOOP [ij is straightforward, based 
on the aforementioned executable specification of the calculus. Executions of SCOOP programs can be 
simulated by simply exploiting the Maude rewriting capabilities, hence the computation of the corresponding 
aliasing information is immediate. 

A similar technique exploiting regular behaviour of (non-concurrent) programs, in order to reason on 
“may aliasing”, was previously introduced in [^. In short, the results in utilize abstract representations 
of programs in terms of finite pushdown systems, for which infinite execution paths have a regular structure 
(or are “lasso shaped”) [s^. Then, in the style of abstract interpretation |^, the collecting semantics is 
applied over the (finite state) pushdown systems to obtain the alias analysis itself. The main difference 
with the results in [34 consists in how the abstract memory addresses corresponding to pointer variables 
are represented. In |34l | these range over a finite set of natural numbers. In this paper we consider alias 
expressions build according to the calculus in [^, based on program constructs. The work in also 
proposes an implementation of pushdown systems in the K-framework. 
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We agree that it could be worth presenting our analysis as an abstract interpretation (AI) [s^ . A mod¬ 
eling exploiting the machinery of AI (based on abstract domains, abstraction and concretization functions, 
Galois connections, fixed-points, etc.) is an interesting topic left for future investigation. 

An immediate direction for future work is to identify interesting (industrial) case studies to be analyzed 
using the framework developed in this paper. We are also interested in devising heuristics comparing the 
efficiency and the precision {e.g., the number of false positives introduced by the alias approximations) 
between our approach and other aliasing techniques. 

Another research direction is to derive alias-based abstractions for analyzing concurrent programs. We 
foresee possible connections with the work in on concurrent Kleene algebra formalizing choice, iteration, 
sequential and concurrent composition of programs. The corresponding definitions exploit abstractions of 
programs in terms of traces of events that can depend on each other. Thus, obvious challenges in this respect 
include: (i) defining notions of dependence for all the program constructs in this paper, (ii) relating the 
concurrent Kleene operators to the semantics of the SCOOP concurrency model and (hi) checking whether 
fixed-points approximating the aliasing information can be identified via hxed-point theorems. 

Furthermore, it would be worth investigating whether the graph-based model of alias relations introduced 
in can be exploited in order to derive finite K specifications of the extended alias calculus. In case of 
a positive answer, the general aim is to study whether this type of representation increases the speed of 
the reasoning mechanism, and why not - its accuracy. With the same purpose, we refer to a possible 
integration with the technique in [38| that handles point-to graphs via a stack-based algorithm for fixed- 
point computations. 

Related to deadlock detection, the second contribution of this paper, we provided a formalization based 
on sets of acquired resources and sets of handlers processors wait to lock in their attempt to execute 
asynchronously. This definition corresponds to Coffman deadlocks in the context of SCOOP, occurring 
whenever there is a set of processors reserving each other circularly. We introduced the equivalent SCOOP 
semantic rule and discussed the results of using Maude in order to analyze deadlocks in the context of a Dining 
Philosophers scenario. On the one hand, the SCOOP semantics in [fj is very large, as it incorporates all the 
aspects of a real concurrency model. On the other hand, the formalization in [l| was tailored for reasoning 
about the SCOOP model, and not necessarily about SCOOP applications, hence it includes design decisions 
(such as index-based naming of communication channels) that make the state space grow unacceptably 
large for model-checking purposes. As a workaround for the model-checking issue, we presented the idea 
behind building an abstract semantics of SCOOP based on aliases, together with a series of implementation 
improvements that eventually enabled the Maude LTL model-checker to correctly identify deadlocks. A 
survey on abstracting techniques on top of Maude executable semantics is provided in Q. 

The literature on using static analysis Q and abstractin g te chniques for (related) concurrency models 
is considerable. We refer, for instance, to the recent work in (39| that introduces a framework for detecting 
deadlocks by identifying circular dependencies in the (hnite state) model of so-called contracts that abstract 
methods in an 00-language. Nevertheless, the integration of a deadlock analyzer in SCOOP on top of Maude 
is an orthogonal approach that aims at constructing a RL-based toolbox for SCOOP programs laying over 
the same semantic framework. 

In [43 SCOOP programs are verified for deadlocks and other behavioral properties using GROOVE [^. 
The work in 0 proposes a redefinition of the most common features of the SCOOP semantics based on 
graph transformation systems (GPSs). This is a bottom-up approach, as it aims at redefining the SCOOP 
semantics from scratch via GPSs, orthogonal to our rather top-down strategy of narrowing the original 
semantics proposed in [I|. 

As a clear direction for future work we consider designing and analyzing deadlock situations for more 
SCOOP applications. Based on the experience so far, this would help better understand and observe the 
SCOOP state space, thus providing hints for further improvements in the context of model-checking, for 
instance. As we could already see, major advances in this regard are obtained when semantically equivalent 
states are identified and collapsed within the same equivalence classes. This was the case of the indexed- 
based communication channels in Section 16.31 Similar redundant states are introduced by the so-called 
“regions” in SCOOP “administrating” objects handled by the same processor. We foresee their elimination 
would speed-up the LTL model-checker. 
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